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Abstract 

In this paper we present CIDER (Curry Integrated Development EnviRonment), 
an analysis and programming environment for the declarative multi-paradigm lan- 
guage Curry. CIDER is a graphical environment to support the development of Curry 
programs by providing integrated tools for the analysis and visualization of programs. 
CIDER is completely implemented in Curry using libraries for GUI programming 
(based on Tcl/Tk) and meta-programming. An important aspect of our environment 
is the possible adaptation of the development environment to other declarative source 
languages (e.g., Prolog or Haskell) and the extensibility w.r.t. new analysis methods. 
To support the latter feature, the lazy evaluation strategy of the underlying imple- 
mentation language Curry becomes quite useful. 

1 Overview 

CIDER is a graphical programming and development environment for the construction 
and debugging of declarative multi-paradigm programs. Although the current implemen- 
tation of CIDER is targeted at the multi-paradigm programming language Curry [[Tcfl , 
the intension is to provide a development platform for both functional and logic lan- 
guages since Curry integrates the most important features from functional programming 
(nested expressions, lazy evaluation, higher-order functions), logic programming (logical 
variables, partial data structures, built-in search), and concurrent programming (concur- 
rent evaluation of expressions with synchronization on logical variables). In particular, 
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the implementation of CIDER is based on an intermediate language to which functional, 
logic, and also integrated functional logic programs can be compiled (e.g., see || ^, [l7[|). 
Thus, CIDER can be adapted to other declarative languages provided that there exists a 
front end to compile programs into this implementation-independent format (there exists 
also an XML representation for this intermediate language, see ||). 

CIDER is an environment where various analysis and debugging tools for declarative 
multi-paradigm languages are available. Since the development of such tools is still an 
ongoing research, CIDER is not designed as a closed system but it is intended as an open 
platform to integrate various tools for analyzing and debugging programs. Currently, 
CIDER consists of 

• a program editor with the usual functionality, 

• various tools for analyzing properties of functions defined in a program (types, over- 
lapping definitions, complete definitions, dependencies etc), 

• a tool for drawing dependency graphs, 

• a graphical debugger, i.e., a visualization of the evaluation of expressions. 

To get an impression of the use of CIDER, Fig. [l] shows a snapshot after starting CIDER 
and loading a program. The main window in the middle is an editor window for the current 
program. On the left- and right-hand side, there is a list of the top-level functions in the 
current file and a list of the currently available analysis tools (see below for a description) , 
respectively. After selecting a function and an analysis in the corresponding list boxes, 
the function is analyzed and the analysis result is either shown in the bottom window (if 
it is a textual result) or, if it is a graph, it is visualized with the graph visualization tool 
daVinciQ. The current version of CIDER contains the following analysis tools (which are 
useful but very simple and mainly included for demonstration issues; see also Section || 
for a description on how to add new analysis tools): 

Get Type: Computes the function's type. 

Overlapping Rules: Shows whether the function is defined by overlapping rules (which 
might cause non-deterministic evaluations even for ground expressions). This is 
interesting for logic programming but might be also useful for purely functional 
programs. 

Completeness: Shows whether the function completely defined, i.e., reducible on all 
ground constructor terms. Due to possible overlapping rules, the current implemen- 
tation is based only on a sufficient criterion, i.e., the analysis results are "complete" 
or "might be incomplete". 

1 |http : //www . tzi . de/daVinci/ 
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[•] Curry Integrated Development EnviRonment (Version of 16/1 0/2001) 
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-- quicksort : 

qsort : : [Int] -> [Int] 

qsort [] - [] 

qsort (x:l) = qsort (filter (gt x) 1) 

gt k y = k > y 
leq t: y = x <= y 

Lain = qsort [5,0,3,1,2,4,8,6,9,7] 



x : qsort (filter (leq x) 1) 



append : [t] -> [t 
append eval flex 



i -> it] 
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Parsing ' /usr/local/home/mh/cider/demo. curry' . . 
/home/mh/pakcs/lib /prelude curry compilation completed 

¥arning: /uer/local/home/mh/cider/demo. curry : 12 : 7 unreferenced variable " 
/usr/local/home/mh/cider/demo. curry : compilation completed with 1 warnings, 
translating to /usr/local/home/mh/cider/demo. flc ... 



Figure 1: The main window of CIDER 



(D/ 1) Dependency: Direct/indirect dependency, i.e., all functions that are directly or in- 
directly called in the rules defining this function. 

Called By: Computes the list of all functions that call this function in their defining rules. 

Dead Code: Computes the list of all top-level functions in the currently loaded module 
that are not reachable from the selected function. 

DGraph: Shows the dependency graph for the selected function. This is a mixture as well 
as a graphical visualization of (D/I) Dependency, i.e., an arc is drawn from each 
function symbol to all functions directly called in the rules defining this function 
and all reachable function nodes are included in the graph. 

For instance, the visualization computed by the analysis DGraph for the function qsort 
(compare Fig. |]) is shown in Fig. ||. 

Finally, CIDER contains also a graphical debugger /tracer to visualize the evaluation 
of expressions. Due to the fact that the operational semantics of the considered language 



is important for this part of the programming environment, we discuss it in Section 3.4 
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Figure 2: Visualization of a program dependency graph 



The rest of this paper is structured as follows. The next section provides a short 
overview of the main features of Curry as relevant for this paper. Section || surveys the 
implementation of our programming environment. Section || sketches the necessary tasks 
to add new analysis tools to CIDER. Finally, Section l| contains our conclusions. 



2 Basic Elements of Curry 

Although we mentioned above that our programming environment can be adapted to other 
declarative languages than Curry, the main motivation for the development of CIDER (and 
also Curry itself) is to provide a common platform for declarative programming where 
the most important declarative paradigms are smoothly integrated. Therefore, Curry is 
our main target language and we review in this section those elements of Curry which 
are necessary to understand the functionality and implementation of our programming 
environment. More details about Curry's computation model and a complete description 
of all language features can be found in fln], 16]. 



Curry is a modern multi-paradigm declarative language combining in a seamless way 
features from functional, logic, and concurrent programming and supports programming- 
in-the-large with specific features (types, modules, encapsulated search). From a syntactic 
point of view, a Curry program is a functional program extended by the possible inclusion 
of free (logical) variables in conditions and right-hand sides of defining rules. Curry has 



a Haskell-like syntax [21], i.e., (type) variables and function names usually start with 



lowercase letters and the names of type and data constructors start with an uppercase 
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letter. The application of / to e is denoted by juxtaposition ("/ e"). 

A Curry program consists of the definition of functions and the data types on which 
the functions operate. Functions are evaluated in a lazy manner. To provide the full 
power of logic programming, functions can be called with partially instantiated arguments 
and defined by conditional equations with constraints in the conditions. The behavior 
of function calls with free variables depends on the evaluation annotations of functions 
which can be either flexible or rigid. Calls to rigid functions are suspended if a demanded 
argument, i.e., an argument whose value is necessary to decide the applicability of a rule, 
is uninstantiated {"residuatiori'''). Calls to flexible functions are evaluated by a possibly 
non-deterministic instantiation of the demanded arguments to the required values in order 
to apply a rule {"narrowing"). 

Example 1 The following Curry program defines the data types of Boolean values and 
polymorphic lists (first two lines) and functions for computing the concatenation of lists 
and the last element of a list: 

data Bool = True | False 
data List a = [] I a : List a 

cone : : [a] -> [a] -> [a] 

cone eval flex — specify evaluation mode of cone as "flexible" 

cone [] ys = ys 

cone (x:xs) ys = x : cone xs ys 

last xs | cone ys [x] =:= xs = x where x,ys free 

The data type declarations define True and False as the Boolean constants and [] (empty 
list) and : (non-empty list) as the constructors for polymorphic lists (a is a type variable 
ranging over all types and the type "List a" is usually written as [a] for conformity with 
Haskell). 

The (optional) type declaration (": :") of the function cone specifies that cone takes 
two lists as input and produces an output list, where all list elements are of the same 
(unspecified) type.0 Since cone is explicitly defined as flexible^] (by "eval flex"), the 
equation "cone ys [x] =:= xs" can be solved by instantiating the first argument ys to 
the list xs without the last argument, i.e., the only solution to this equation satisfies that 
x is the last element of xs. 

In general, functions are defined by [conditional) rules of the form 
"Z I c =e where vs free" where Z has the form ft\...t n with / being a func- 
tion, t\,...,t n data terms and each variable occurs only once, the condition c is a 

2 Curry uses curried function types where a->(3 denotes the type of all functions mapping elements of 
type a into elements of type /3. 

3 As a default, all functions except for constraints are rigid. 
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constraint, e is a well-formed expression which may also contain function calls, lambda 
abstractions etc, and vs is the list of free variables that occur in c and e but not in I (the 
condition and the where parts can be omitted if c and vs are empty, respectively). The 
where part can also contain further local function definitions which are only visible in this 
rule. A conditional rule can be applied if its left-hand side matches the current call and 
its condition is satisfiable. A constraint is any expression of the built-in type Success. 
Each Curry system provides at least equational constraints of the form e\ = : = ei which 
are satisfiable if both sides e± and ei are reducible to unifiable data terms (i.e., terms 
without defined function symbols). However, specific Curry systems can also support 
more powerful constraint structures, like arithmetic constraints on real numbers or finite 
domain constraints, as in the PAKCS implementation [13]. 

Concurrent programming is supported by the concurrent conjunction operator "&" on 
constraints, i.e., a non-primitive constraint of the form u c\ k C2" is evaluated by solving 
both constraints c\ and C2 concurrently. Since suspension is controlled by the instantiation 
of arguments in calls to rigid functions, concurrent computations are synchronized in a 
high-level manner by logic variables as in concurrent constraint programming p2| . 

The operational semantics of Curry, precisely described in [|l(], 16], is a conservative 
extension of lazy functional programming (if no free variables occur in the program or the 
initial goal) and (concurrent) logic programming. Since it is based on an optimal evalu- 
ation strategy 0], Curry can be considered as a generalization of concurrent constraint 
programming J2<| with a lazy (optimal) evaluation strategy. Due to this generalization, 
Curry supports a clear separation between the sequential (functional) parts of a program, 
which are evaluated with an efficient and optimal evaluation strategy, and the concurrent 
parts, based on the concurrent evaluation of constraints, to coordinate concurrent program 
units. 

The concurrent conjunction operator "&" is a basic combinator to create a fixed network 
of concurrent activities. However, this primitive is too limited when a dynamically varying 
number of processes with many-to-one communication structures should be modeled, since 
this requires the merging of message streams from different processes into a single message 
stream. Doing that with a merger function causes a set of problems as discussed in [ ]TT| , pj[j . 
Therefore, Janson et al. [18] proposed the use of ports for the concurrent logic language 
AKL which are generalized in [|ll]] to support distributed programming in Curry. In 
principle, a port is a constraint between a multiset and a stream which is satisfied if the 
multiset and the stream contain the same elements (messages). In Curry a port is created 
by a constraint "openPort p s" where p and s are free logical variables. This constraint 
creates a multiset and a stream and combines them over a port. Elements can be inserted 
into the multiset by sending them to p by the constraint "send m p". When a message 
is sent to p, it will automatically be added to the stream s in order to satisfy the port 
constraint. To support the implementation of distributed systems, where the processes 
run on different machines, ports can be also made externally accessible by assigning a 
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symbolic name to them. For instance, the I/O actionF] (openNamedPort "name") opens 
an external port with symbolic name name and returns the (infinite and lazy) stream of 
incoming messages. If this port has been opened on machine m, clients can access this port 
by executing the I/O action (connectPort "name©m"). This returns a port p to which 
they can send their messages. Note that messages can also contain logical variables which 
provides for a high-level mechanism to return values by instantiation (rather than creating 
reply channels, see The port concept has been used to integrate object-oriented 

features into Curry jl4| which are often necessary in GUI (Graphical User Interface) 
programming to keep the state of user interfaces . 

3 Implementation 

In this section we provide an overview on the implementation of CIDER. This can be also 
seen as an example to show that high-level declarative languages provide the appropriate 
abstractions to implement such advanced application in a modular and extensible way. 
More details about the design and implementation of CIDER can be found in fl9fl . 

3.1 Intermediate Representation Language 

In order to provide a high-level language for implementing new analysis tools to be in- 
tegrated in our programming environment (see also Section ||), CIDER is completely 
implemented in Curry. In order to implement program analyzers, one needs a representa- 
tion of programs as data objects. For representing functional logic programs, the direct 
representation of all program rules is not adequate since the particular pattern-matching 
strategy is quite important to reduce the search space and the length of derivations ||] 
and concrete languages often differ in this strategy. An appropriate data structure to 
describe such strategies are definitional trees, introduced in 0]. More recent approaches 
to the manipulation of functional logic programs (e.g., J|, ||7[l7]]) advocate the explicit 
representation of pattern matching by means of case constructs. 

In the context of functional logic languages, it is necessary to distinguish two kinds 
of case expressions in order to specify the flexible/rigid status of functions. To be 
more precise, we assume that all functions are defined by one rule whose left-hand 
side contains only pairwise different variables as parameters and the right-hand side 
contains case expressions for pattern matching. Thus, the basic syntax of programs in 
this representation can be summarized as follows: 



4 See for a description of the monadic I/O concept of Haskell which has been adapted without 
changes to Curry. 
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P ::= Di . . . D m e ::= v (variable) 

D ::= f Vi . . . v n = e c e± . . . e„ (constructor) 

/ ei . . . e n (function call) 

l> :: <■ ri . . r„ case e of {pi -> e%; . . . ;p n — ► e n } (rigid case) 

fcase eo of {pi — > e\; . . . ;p n — > e„} (flexible case) 

ei or ei (disjunction) 

where P denotes a program, D a function definition, p a pattern and e an arbitrary 
expression. A program P consists of a sequence of function definitions D such that the 
left-hand side has pairwise different variable arguments and the right-hand side is an 
expression e composed by variables, constructors, function calls, case expressions, and 
disjunctions. A case expression has the form (f)case e of {c\ — ► ei, . . . , Cfe — > e^}, 
where e is an expression, ci,...,q. are different constructors of the type of e, and 
ei, . . . , efc are expressions. The pattern variables are local variables which occur only 
in the corresponding subexpression ej. The difference between case and /case shows up 
when the argument e is a free variable: case suspends (which corresponds to residuation) 
whereas fcase nondeterministically binds this variable to the pattern in a branch of the 
case expression (which corresponds to narrowing). 

Example 2 Consider the rules defining the (rigid) function 

^ n = True 

Succ m = False 

Succ m ^ Succ n = m ^ n 

These rules can be represented by the following rule in our representation: 

x ^ y = case x of {0 — > True; 

Succ Xi — > case y of {0 — > False; 

Succ y t -> Xi < yi} } 

Based on this representation, some of the analyses discussed in Section |l|, like the analysis 
for overlapping rules or completely defined functions, can be implemented in a straightfor- 
ward manner by analyzing the structure of case expressions. In order to cover all features 
of functional logic languages, the definition of expressions can be extended by a few addi- 
tional constructs, like higher-order applications (" apply e\ e2"), partial applications, calls 
to external functions, and existential quantification of variables (e.g., see Q). Programs in 
this language, which is also called FlatCurryf\, can be simply represented as data objects 
by a set of data type declarations similarly to Example |l[ For instance, an entire program 
module is represented as an expression of the type 

data Prog = Prog String [String] [TypeDecl] [FuncDecl] 

5 |http : //www . inf ormatik.uni-kiel . de/~ curry /flat/| 
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[OpDecl] [Translation] 

where the arguments of the data constructor Prog are the module name, the names of all 
imported modules, the list of all type, function, and infix operator declarations and a table 
to map external into internal names and vice versa. Furthermore, a function declaration 
is represented as 

data FuncDecl = Func String Int TypeExpr Rule 

where the arguments are the name, arity, type, and rule (of the form 
"Rule arguments expr") of the function (here we omit the other data type declarations). 
The PAKCS implementation of Curry |l3| provides a library Flat for meta-programming 
which contains the definition of such data types (also for representing data type decla- 
rations) and an I/O action for reading a program file and translating its contents into a 
Prog term. 

The FlatCurry representation of programs has been used as an intermediate language 
to compile Curry j|, |6| or similar functional logic programs [17] and to optimize declarative 



programs by partial evaluation |T], £|. However, it should be clear that this representa- 
tion is not restricted to Curry. Purely functional programs can be translated into this 
intermediate language without the use of fcase and or constructs. Purely logic languages 
have only constraints as functions and do not use the case construct (although this could 
be used for the translation of logic languages with coroutining). For instance, the Prolog 
program 

app([] ,Ys,Ys) . 

app([X|Xs] ,Ys, [X|Zs]) :- app(Xs , Ys , Zs) . 

can be translated into the Curry program 
app [] ys zs = (ys =:= zs) 

app (x:xs) ys (z:zs) = (x =:= z) &> (app xs ys zs) 

where "&>" denotes the sequential ("left-to-right") conjunction of constraints (replacing 
"&>" by the concurrent conjunction "&" corresponds to a logic program with coroutining). 
Note that the introduction of auxiliary variables and explicit equality constraints is nec- 
essary due to the left-linearity requirement in Curry. The latter rules can be translated 
into the following FlatCurry definition: 



app xs ys zs = 

fcase xs of { [] — > ys =:= zs; 

x:xl — > fcase zs of 

{ z:zl — ► (x =:= z) &> (app xl ys zl) } } 
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3.2 Program Analysis 

As shown in Section [l], our programming environment is intended to integrate various 
analysis tools for declarative programs. This demands for a unique interface for the im- 
plementation of each program analysis to be integrated into CIDER. Since the intermediate 
language FlatCurry is a reasonable basis for writing program analyzers, we require that 
each program analyzer must implement a function of type 

type ProgAnalysis = Prog -> [ (String, AnaRes)] 

where 

data AnaRes = Message String | Graph DvGraph 

is the result type of analyzing an individual function in a program. Thus, a program 
analysis takes a program as input (Prog) and produces a list of analysis results, where each 
analysis result is a pair consisting of a function name and the associated result of analyzing 
this function. In our current implementation, it is sufficient that this result is either a 
string s ("Message s", e.g., the type of a function, "overlapping" / "not overlapping", the 
list of called functions) to be shown in the bottom window of the main interface, or a 
graph g ("Graph g" , e.g., the function's dependency graph) to be visualized in separate 
window with the graph visualization tool daVinci (see Fig. ||). 

As a simple example, the analysis of overlapping rules can be implemented as follows: 

analyseOverlappings : : Prog -> [(String, AnaRes)] 
analyseOverlappings (Prog _ funs _) = map overlapFun funs 
where overlapFun (Func name _ _ (Rule e)) 

I orlnExpr e = (name, Message "overlapping") 

I otherwise = (name, Message "not overlapping") 

where the function orlnExpr checks for occurrences of disjunctions in an expression. 

It is interesting to note that the lazy evaluation strategy of our implementation lan- 
guage Curry becomes quite handy here. Although a program analysis is defined as a 
function operating on the entire program, which may cause a complex computation, the 
lazy evaluation strategy performs the program analysis in a demand-driven manner. If a 
user selects an analysis (in the right window of the main interface, see Fig. [l]), the cor- 
responding analysis function is applied to the currently loaded program module. Due to 
lazy evaluation, this application is not evaluated at this analysis selection time but only if 
the user selects an individual function in the left window of the main interface. If such a 
function is selected, the analysis is performed to show its result. However, note that only 
the selected function is analyzed which can be done locally (e.g., "overlapping" analysis) 
or might require the consideration of other parts of the program (e.g., computing the de- 
pendency graph). Furthermore, if the same function is selected again, the result is directly 
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available due the fact that lazy evaluation evaluates each expression at most once. This 
behavior is very desirable for our environment. In a strict or imperative language, one 
needs some additional effort to implement such a behavior. 

3.3 Main Interface 

The main graphical user interface (see Fig. |l]) is implemented with the library Tk which sup- 
ports a high-level implementation of GUIs in Curry by exploiting the integrated functional 
and logic features of the language [12]. With this library, the structure of the interface 



(i.e., the different widgets) is described as a data term containing call-back functions for 
implementing the functionality of the individual widgets. 

One difficulty in the implementation of user interfaces in a declarative language is the 
handling of internal states. This is necessary for keeping the name of the currently loaded 
program module, the selected program analysis, the selected function etc. GUI libraries 
for purely functional languages (e.g., ||) advocates the use of monads for this purpose. 
Since our GUI library is not based on monads but exploits the functional and logic features 
of Curry, we handle the internal state of the GUI in an object-oriented style by exploiting 
Curry's port concept sketched in Section [2|. Thus, the state of the main interface is kept as 
an argument of a recursive function implementing a "GUIServer". Basically, this function 
has type 

serveGUI : : GUIServerState -> [GUIServerMsg] -> Success 

where GUIServerState contains all data in the state of the main interface and 
GUIServerMsg are the messages to be processed by the server. This function is imple- 
mented by a case distinction on the different first messages where the function is (tail 
recursively) called with a modified state (depending on the message) and the list of re- 
maining messages. For instance, the message Terminate terminates the server and the 
message "SetAna o" sets the current program analysis. Thus, we have the following defin- 
ing rules, among others (the function changeAna computes a new state with a changed 
current analysis component): 

serveGUI _ (Terminate : _) = success — the end, no recursive call 

serveGUI state (SetAna a : msgs) = serveGUI (changeAna a state) msgs 

Now, the main interface is implemented as a GUI (based on the Tk library as discussed 
above) where the call-back functions only send messages to the GUI server. For instance, 
if the user selects an analysis a, the message "SetAna a" is sent. The GUI server is also 
responsible to compute the analysis results when they are requested by the GUI. More 
details about this technique to keep states in GUIs can be found in [12]. Moreover, [111] 



contains a general description of the object-oriented functional logic programming style 
applied here. 

It is interesting to note that the separation of the implementation into the GUI itself 
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Figure 3: Visualization of a (concurrent) computation 



and the GUI server provides also the possibility to move the computation-intensive tasks 
to a powerful "compute server" with only minor changes in our implementation. Since 
a port can be also made externally accessible (by changing the method to create a port, 
i.e., replacing openPort by openNamedPort, see Section ^), we can start the GUI server 
on another machine than the GUI itself. This requires only a change of two program lines 
(replacing internal by external ports) in our implementation and might be reasonable for 
more complex program analyses. 

3.4 Graphical Tracer 

As mentioned at the beginning, CIDER also contains a graphical debugger /tracer to vi- 
sualize the evaluation of expressions. The debugger always shows the expressions as trees 
although some parts of the expressions are actually shared. If a subexpression is reduced, 
all identical subexpressions shared with this subexpression are also reduced in the same 
step in order to be conform with Curry's operational semantics (which is based on sharing 
to support laziness, cf. Q). The subexpression reduced in the next step (the next redex) 
is always colored in red. Similarly, a variable is colored in red if it will be bound in the next 
step. This is quite useful to visualize the execution of concurrent computations which are 
synchronized in Curry by the instantiation of logical variables (compare Section ^) . One 
can trace forward and backward through all evaluation steps. Furthermore, one can also 
set a breakpoint to skip uninteresting parts of a computation. A snapshot of the debugger 
is shown in the Fig. |3[ 

The debugger is implemented as a meta-interpreter for (Flat) Curry in Curry, i.e., it 
is based on a "step function" that maps a single (FlatCurry) expression into a list of 
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expressions according to the operational semantics of Curry as denned in 1C, 16|. The 
resulting list of expressions collects all "don't know" alternatives of a single evaluation 
step, e.g., for purely functional programs this list contains at most one element. Since 
the debugger works on the level of FlatCurry expressions, it can visualize all kinds of 
computations including concurrency, higher-order functions, etc. As a drawback, it has 
only a limited performance but, nevertheless, it is useful to explain and understand the 
computation model of Curry. Thus, the debugger is intended as a teaching tool to visualize 
the operational semantics of Curry rather than a tool to locate bugs in larger programs. 
For the latter purpose, it might be interesting to develop more efficient debuggers as done 
for purely lazy functional languages (e.g., j/J). The visualization part of our debugger is 
also implemented in Curry by the use of the Tk library. 



4 Extending the Development Environment 

This section discusses how one can extend the current development environment in various 
directions. We already mentioned that CIDER should integrate various analysis tools for 
declarative programs. In order to add a new analysis, one has to implement it as a function 



of type ProgAnalysis (see Section 3^). For the simple addition of new analysis tools, our 
implementation has a configuration module which contains the definition of a constant 

anaList : : [(String, ProgAnalysis)] 

This constant specifies the list of all currently available analyses, i.e., the first component 
of each entry is the name of the analysis (shown in the right column of the main window) 
and the second component is the implementation of the analysis as a function as described 
above. For instance, the current definition of anaList contains an element 

("Overlapping Rules" ,analyseOverlappings) 

(compare Section |3.2| ). Therefore, in order to integrate a new analysis into CIDER, one 
only needs to add a new element to this list, recompile the CIDER system, and the new 
analysis is easily accessible through the graphical interface. 

Another possible extension of CIDER is the language of programs to be loaded and an- 
alyzed. As explained above, CIDER is based on the FlatCurry representation of programs 
which can be also used for other source languages (e.g., Prolog, Haskell, or Toy ^0|). Since 
the program editor in the main window is just a standard text editor, CIDER is largely 
independent of the concrete syntax of the source language. Thus, in order to adapt CIDER 
to another source language X, one only needs to replace the Curry front end (which is 
used in the GUI server to load source programs) by another front end that translates 
X programs into the corresponding FlatCurry representation. [] Thus, the configuration 

6 If the source language X also re quir es a different operational semantics of FlatCurry, then the imple- 



mentation of the tracer (see Section 3.4 ) must be changed, too 
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\*\ Curry Integrated Development EnviRonment (Version of 16/1 0/2001) 
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Figure 4: CIDER adapted to the source language Prolog 



module of CIDER contains also the definition of the actual preprocessor that translates 
source programs into the corresponding FlatCurry representation. For instance, we have 
implemented such a preprocessor for pure Prolog programs and Fig. |] shows the main 
window of CIDER after loading and analyzing a Prolog program with this preprocessor. 



5 Conclusions 

We have presented CIDER, a graphical programming and development environment for 
declarative multi-paradigm programs. The main motivation of CIDER is to support the 
construction and debugging of programs by offering a wide range of analysis tools in an 
integrated manner. Although the current implementation offers only a few basic analysis 
tools and is targeted at the language Curry, we have also shown that it is fairly easy to 
extend CIDER with new analysis tools or adapt it to a new declarative source language. 
As far as we know, CIDER is the first development environment for declarative multi- 
paradigm programs designed to integrate various analysis tools. The mostly related system 
is IT>£ Q , a graphical development environment for the functional logic languages Toy and 
Curry. IDS supports the writing of programs in a standard text editor window and the 
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compilation and execution of programs. However, ZT>8 does not offer tools for analyzing 
and debugging programs. 

CIDER is completely implemented in Curry and we have discussed how advanced 
programming techniques are exploited in this implementation. For instance, functions 
as first-class citizens are useful to apply higher-order programming techniques in the im- 
plementation of analysis tools or to integrate such tools as functions in data structures. 
Laziness is practical to define a program analysis in a conceptual clean manner but com- 
pute only those parts that are actually required by the user. Furthermore, concurrent 
programming is useful to structure and distribute the various tasks possibly on different 
machines. 

The code size of the complete implementation of CIDER is approximately 1400 lines of 
Curry code. This includes the implementation of the graphical user interface, the various 
analysis tools, and the meta-interpreter and graphical tracer. In addition, the total size of 
all imported system libraries is approximately 1500 lines of Curry code. These numbers 
indicate the advantage of the use of declarative high-level programming languages in the 
implementation of complex systems. 

The implementation of CIDER is freely available from the web page 
http://www.informatik.uni-kiel.de/~pakcs/cider/ and requires only an in- 
stalled Curry system with the libraries for application programming distributed with the 
PAKCS implementation 

For future work we intend to add more analysis tools, in particular, advanced type- 
based analysis tools which can be used to analyze particular properties of multi-paradigm 
programs JTIf]. Furthermore, better (declarative) debugging tools should be integrated 
into CIDER as well as the direct efficient execution of programs by connecting compilers 
based on FlatCurry, like ||. 
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